Foundation for Intelligent Physical Agents

Architecture Concrete realization: CORBA Elements Concrete realization: Java Elements Messaging Directory ACL Messaging Directory ACL Figure 1: Abstract Architecture Mapped to Various Concrete Realizations The abstract architecture also describes optional elements. Although an element is optional at the abstract level, it may be mandatory in a particular realization. That is, a realization may require the existence of an entity that is optional at the abstract level (such as a message-transport-service), and further specify the features and interfaces that the element must have in that realization. It is also important to note that a realization can be of the entire architecture, or just one element. For example, a series of concrete specifications could be created that describe how to represent the architecture in terms of particular programming language, coupled to a sockets based message transport. Messages are handled as objects with that language, and so on. On the other hand, there may be a single element that can be defined concretely, and then used in a number of different systems. For example, if a concrete specification were created for the directory-service element that describes the schemas to use when implemented in LDAP, that particular element might appear in a number of different agent systems. © 2000 Foundation for Intelligent Physical Agents FIPA Abstract Architecture 7 Abstract Architecture Messaging Directory ACL Concrete realization: C++ & SMTP Messaging ACL Concrete realization: Java Elements Messaging ACL LDAP Directory Services Figure 2: Concrete Realizations Using a Shared Element Realization In this example, the concrete realization of directory is to implement the directory services in LDAP. Several realizations have chosen to use this directory service model. 2.5 Methodology This abstract architecture was created by the use of UML modelling, combined with the notions of design patterns as described in [Gamma95]. Analysis was performed to consider a variety ways of structuring software and communications components in order to implement the features of an intelligent multi-agent system. This ideal agent system was to be capable of exhibiting execution autonomy and semantic interoperability based on an intentional stance. The analysis drew upon many sources: • The abstract notions of agency and the design features that flow from this. • Commercial software engineering principles, especially object-oriented techniques, design methodologies, development tools and distributed computing models. • Requirements drawn from a variety of applications domains. • Existing FIPA specifications and implementations. • Agent systems and services, including FIPA and non-FIPA designs. • Commercially important software systems and services, such as Java, CORBA, DCOM, LDAP, X.500 and MQ Series. The primary purpose of this work is to foster interoperability and reusability. To achieve this, it is necessary to identify the elements of the architecture that must be codified. Specifically, if two or more systems use different technologies to achieve some functional purpose, it is necessary to identify the common characteristics of the various approaches. This leads to the identification of architectural elements: abstract designs that can be formally related to every valid implementation. For example, one agent system may transmit ACL messages using the OMG IIOP protocol. A second may use IBM’s MQ-series enterprise messaging system. An analysis of these two systems – how senders and receivers are identified, and how messages are encoded and transferred – allows us to arrive at a series of architectural abstractions involving messages, encodings, and addresses. © 2000 Foundation for Intelligent Physical Agents FIPA Abstract Architecture 8 In some areas, the identification of common abstractions is essential for successful interoperation. This is particularly true for agent-to-agent message transfer. The end-to-end support of a common agent communication language is at the core of FIPA's work. These essential elements, that correspond to mandatory implementation specifications are here described as mandatory architectural elements. Other areas are less straightforward. Different software systems, particularly different types of commercial middleware systems, have specialized frameworks for software deployment, configuration, and management, and it is hard to find common principles. For example, security and identity remain tend to be highly dependent on implementation platforms. Such areas will eventually be the subjects of architectural specification, but not all systems will support them. These architectural elements are optional. This document models the elements and their relationships. In Section 3, Themes of the Abstract Architecture there is an holistic overview of the architecture. In Section 4, Architectural Overview there is a structural overview of the architecture. In Section 5, Architectural Elements, each of the architectural elements is described. In Section 6, Agent and Agent Information Model there are diagrams in UML notation to describe the relationships between the elements. 2.6 Status of the Abstract Architecture There are several steps in creating the abstract architecture: 1. Modelling of the abstract elements and their relationships. 2. Representing the other requirements on the architecture that cannot be modelled abstractly. 3. Describing interoperability points. This document represents the first item in the list. It is nearing completion, and ready for review. The second step is satisfied by guidelines for instantiation. This document will not be written until at least one implementation based on the abstract architecture has been created, as it is desirable to base such a document on actual implementation experience. Interoperability points and conformance are defined by specific interoperability profiles. These profiles will be created as required during the creation of concrete specifications. 2.7 Evolution of the Abstract Architecture It is important that a document such as this be able to change to reflect new technologies and software engineering practices, and to correct errors, mistakes or poor choices. However extreme care must be taken when proposing any change, since an ill-considered change could, in principle, invalidate all concrete architectural specifications which are based upon this document. For this reason it is recommended that new architectural elements be introduced only after they have been the subjects of substantial practical experience. When in doubt, new elements should be proposed as optional elements, and restricted to mutually consenting platform implementations. New properties and relationships for existing architectural elements must be introduced in a backward-compatible fashion; specifically, the change must support (and require) that all concrete implementations can incorporate the change in a backward compatible manner. Much of our understanding about how to extend the FIPA architecture will depend on the use of experimental systems. It is useful to be able to deploy and test such systems without breaking "production" systems based on FIPA standard specifications. FIPA may elect to define specific ontologies or extend existing architectural elements in order to support experimental features in a well-behaved fashion. (A parallel may be drawn with the use of RFC-822 email systems, in which experimental elements may be introduced provided that they use names that begin "X-".) One of the challenges involved in creating the current set of abstractions is drawing the line between elements that belong in the abstract architecture and those which belong in concrete instantiations of the architecture. As FIPA creates several concrete specifications, and explores the mechanisms required to properly manage interoperation of these © 2000 Foundation for Intelligent Physical Agents FIPA Abstract Architecture 9 implementations, some features of the concrete architectures may be abstracted and incorporated in the FIPA abstract architecture. Likewise, certain abstract architectural elements may eventually be dropped from the abstract architecture, but may continue to exist in the form of concrete realizations. The current placement of various elements as mandatory or optional is somewhat tentative. It is possible that some elements that are currently optional will, upon further experience in the development of the architecture become mandatory. © 2000 Foundation for Intelligent Physical Agents FIPA Abstract Architecture 10 3 Themes of the Abstract Architecture The overall approach of the abstract architecture is deeply rooted in object-oriented design, including the use of design patterns and UML modelling. As such, the natural way to envision the elements of the architecture is as a set of abstract object classes that can act as the input to the high level design of specific implementations. Although the architecture explicitly avoids any specific model of composing its elements, its natural expression is a set of object classes comprising an agent platform that supports agents and services. The following diagram depicts the hierarchical relationships between the abstraction defined by this document and the elements of a specific instantiation: Abstract Architecture (Naming, Transport, Encoding, Namespace) Agent Communication and Semantics (ACL, Encodings, Interation Procols, etc.)Architecture (Naming, Transport, Encoding, Namespace) Agent Communication and Semantics (ACL, Encodings, Interation Procols, etc.) Concrete Elements (Gateways, Services, Agent Platform)